17章 特殊な制御構造
qst_exe.icon
17.1 ルーチンからの複数のreturn文
return文とexit文はプログラムの制御を任意のルーチンから戻せるようにする制御機構
コードを読みやすくするためには、答えが分かった時点でreturnを使うと良い場合がある
ガード句を使って複雑なエラー処理を単純化する
if文の中に大量のエラー処理が入って正常系の処理がわかりにくくなる場合
不要にreturnを使うとコードを追っていくのが大変になるので、不必要には使わない
早期return禁止とかはあるのかな
17.2 再帰
問題を細分化して、ルーチンでその一部分を解決し、自分自身を呼び出しながら他の部分を解決していく方法
書籍ではソートや迷路が題材
再帰を終了するための手段はあるか
安全カウンタを使って無限再帰を防いでいるか
再帰終了のための手段が複雑な場合には安全カウンタを使う
ルーチン実行時に作成される変数ではなく、クラスのメンバ変数か引数が望ましい
再帰は1つのルーチンに限定されているか
スタックの使用量に注意する
階乗やフィボナッチ数列に再帰を使用しない
初期状態, 終了状態が分かれば再帰は分かる
数学的に書けるのがメリットかな
17.3 goto文
gotoは今でも使われている
特定条件下で適切に使用するならいいよ
goto文を使ったことがないので、使ったことある人の意見が聞きたい
17.3.1 goto文反対論
goto文がない方がコードの品質が良い
goto文があるとコードのフォーマットが難しい
コンパイラの最適化が無効になる
コードが上から下に流れるべきという原則に反している
17.3.2 goto文賛成論
コードの重複が無くなる
処理を1箇所にまとめることでリソースの削減ができる
goto文が存在する言語は設計がしっかりしてる言語なので、存在するべき理由があるはず
17.3.3 偽りのgoto文論争
「goto文が悪である」と例に挙げられるコードがたいてい答えありきになっているという話
goto文に限らず、結論ありきの例には注意しないと qst_exe.icon
17.3.4 エラー処理とgoto文
ネストしたif文を使う
状態変数で書き直す
try-finallyで書き直す
17.3.5 goto文とelse句の共有コード
goto文で実行したいelse句がある場合にはルーチン化するのがよい
17.3.6 goto文使用のガイドライン
構造化された制御構造(クラスかな)をサポートしない言語では、それをエミュレートするためだけにgoto文を使う
これをサポートする言語ではgoto文を使用しない
効率よくするためにgoto文を使用する場合には必ずパフォーマンスを計測する
ほとんどの場合にはgoto文を使用しなくても効率は低下しない
構造化された制御構造をエミュレートする場合を除き、gotoは1ルーチンにつき1つ
構造化された制御構造をエミュレートする場合を除き、gotoは前方に進むものだけにする
すべてのgotoが使用されていることを確認する
gotoによってアクセスできないコードがないかを確認する
あなたが管理者である場合は、たった1つのgoto文をめぐって争うことは、敗北に値しないという姿勢でのぞむこと。プログラマが代わりの方法を知っているうえで論争をいとわないという場合は、おそらくgoto文を使用しても問題はない。
gotoといえば...
17.4 特殊な制御構造の展望
今はこのやり方はダメ
goto文知らないけど、何となくダメっぽいのが分かる
そして、かつてはこの方法が望ましかった時代があったことに驚き
goto文を無制限に使用すること
goto文のターゲットを動的に計算し、計算された場所にジャンプすること
goto文を使って1つのルーチンの途中から別のルーチンの途中にジャンプすること
行番号やラベルを使ってルーチンを呼び出し、ルーチンの途中で実行を開始すること
17.5 参考資料
リファクタリング
17.6 まとめ
複数のreturn文は、ルーチンの可読性と保守性を向上させ、深くネストしたロジックを避けるのに役立つ
再帰は、問題の範囲が狭い場合の的確な解決策となる
可読性と保守性の高いコードを書くために、goto文が最善の方法となるケースがいくつかある
そのケースは極稀なので、極力goto文を使わないように書く